Cookie 技術規範 (RFC 6265)： Cookies 是伺服器透過 Set-Cookie 回應標頭，要求客戶端儲存的鍵值對數據。瀏覽器會在後續對同一伺服器的請求中，自動通過 Cookie 標頭將其發回。

Cookie 屬性精解：

Expires/Max-Age：控制 Cookie 的生命週期（持久性 Cookie vs. 會話 Cookie）。

Domain/Path：定義 Cookie 的作用域 (Scope)，控制哪些路徑和子域名會發送此 Cookie。

Secure：強制 Cookie 只在 HTTPS 連線中發送，防止中間人攻擊竊聽。

HttpOnly：禁止 JavaScript 透過 document.cookie API 存取 Cookie，是抵禦 XSS 竊取會話權杖的核心防禦。

SameSite (Strict, Lax, None)：現代瀏覽器中抵禦 CSRF 攻擊的關鍵屬性，限制跨站請求時 Cookie 的發送策略。

會話管理 (Session Management)： 這是一種伺服器端的狀態管理模式。伺服器生成一個高熵 (High-entropy)、無法預測的會話 ID (Session ID)，將其透過 Cookie 發送給客戶端。伺服器自身則維護一個會話儲存（如 Redis, Memcached），將會話 ID 與用戶的詳細狀態數據（登入狀態、權限等）關聯起來。

替代方案 (JWT)： JSON Web Tokens (JWT) 是一種客戶端儲存會話狀態的方案。伺服器將用戶資訊和權限簽名後生成一個 Token，交由客戶端儲存。客戶端在後續請求中攜帶此 Token。這減少了伺服器端的儲存開銷，但帶來了 Token 撤銷困難、簽名演算法配置錯誤 (alg:none) 等新的安全風險。

在 Burp Intruder 中，我可以對 Session ID 進行暴力破解或序列化攻擊。在 Repeater 中，我可以手動移除或修改 Cookie，測試應用的「失效的存取控制」漏洞。我必須學會分析 Cookie 的各個屬性是否配置得當。

我給自己的專業思考題： HttpOnly 標誌如何有效緩解 XSS 攻擊造成的會話劫持？它能完全阻止嗎？如果不能，攻擊者在存在 XSS 漏洞但 Cookie 設置了 HttpOnly 的情況下，還能做些什麼來冒充用戶身份？